Management and authentication in hosted directory service

ABSTRACT

A user, group, and device management and authentication system allows administrators to manage one or more directories with devices that are not associated with a domain of the one or more directories via a set of APIs. The system also allows applications and services that do not have direct access to a list of directory users to access the one or more directories. The user, group, and device management and authentication system may be an add-on system that works in conjunction with a centrally-managed directory service to provide such functionality. For example, the system may generate an access token associated with a particular directory that can be used by a service accessed by an administrator to call an API provided by the system. The API call may be translated into a directory-specific API call that can be used to perform an action in the particular directory.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/456,158, entitled “MANAGEMENT AND AUTHENTICATION IN HOSTED DIRECTORYSERVICE” and filed on Mar. 10, 2017, which is a divisional of U.S.patent application Ser. No. 15/060,236, entitled “MANAGEMENT ANDAUTHENTICATION IN HOSTED DIRECTORY SERVICE” and filed on Mar. 3, 2016,now U.S. Pat. No. 9,596,233, and which is a continuation of U.S. patentapplication Ser. No. 14/500,865, entitled “MANAGEMENT AND AUTHENTICATIONIN HOSTED DIRECTORY SERVICE” and filed on Sep. 29, 2014, now U.S. Pat.No. 9,313,193. All of the above applications are hereby incorporated byreference herein and should be considered a part of this specification.Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication, are hereby incorporated by reference under 37 CFR 1.57.

BACKGROUND

Administrators may utilize directory services to create and maintain adirectory for user, group, device, and/or computing resource managementand/or for providing access to a variety of computing resources (e.g.,file systems, files, users, security policies, network resources,applications, system storage, etc.). For example, the directory servicemay be implemented in a data server operated by an administrator (e.g.,on-premises). The administrator may also operate a plurality of clientdevices, each of which shares a network or domain with the data server.To keep client devices secure and to ensure compatibility across thedomain, the data server may assign and enforce security policies on theclient devices and install or update software running on the clientdevices.

However, installing, maintaining, and operating the data server can beburdensome. The data server itself may include several computingsystems, thus requiring the purchase of expensive hardware and theconfiguring of complex software. In some cases, dedicated facilities forpowering and cooling the data server may be needed as well. Establishingand maintaining connectivity between the data server and the clientdevices may require the installation of expensive network equipment.Furthermore, additional hardware and/or software may be needed toimplement backup and recovery procedures in case the data server failsor data is otherwise lost.

BRIEF DESCRIPTION OF THE DRAWINGS

Throughout the drawings, reference numbers may be re-used to indicatecorrespondence between referenced elements. The drawings are provided toillustrate example embodiments described herein and are not intended tolimit the scope of the disclosure.

FIG. 1 shows an example network environment in which directorymanagement features and user, group, and device management andauthentication features of the present disclosure can be implementedaccording to some embodiments.

FIG. 2A shows interactions to and from the user management andauthentication module during the process of providing a service accessedby a user device with tokens.

FIG. 2B shows interactions to and from the user management andauthentication module during the process of providing tokens andhandling API calls.

FIG. 3 illustrates an authentication process that may be used by acomputing resource service provider system to authenticate anadministrator and provide the administrator with an access token thatcan be used to call APIs provided by the computing resource serviceprovider system to manage one or more directories.

FIG. 4 illustrates an access token usage process that may be used by acomputing resource service provider system to allow an administrator tomanage one or more directories.

DETAILED DESCRIPTION

Introduction

As described above, on-premises data servers that implement directoryservices can be burdensome. Thus, in some conventional systems, amanaged directory service (e.g., a system that stores, organizes, andprovides access to information in a computer operating system'sdirectory, such as MICROSOFT® ACTIVE DIRECTORY®) can be implemented by acentrally-managed data server that is located remotely and shared by aplurality of administrators and/or organizations. The managed directoryservice may manage a plurality of directories. The centrally-manageddata server may provide access to the managed directory service via anetwork (e.g., the Internet) and an administrator may use existingnetwork-enabled client devices to manage the directory. For example, theadministrator may establish an account with the entity providing thecentrally-managed data server. When accessing the account, theadministrator can create one or more directories, create a domain (e.g.,a computer network in which all user accounts and computing resources,such as computers, printers, scanners, services, processes, threads,etc., are registered with a single directory service) within adirectory, and add member servers (e.g., a server that implementslightweight directory access protocol (LDAP), Kerberos, a domain namesystem (DNS) service, or other Active Directory tools to manage recordsin a directory) to the domain. Using a member server added to thedomain, the administrator can create and manage domain users.Accordingly, the administrator can implement a directory service withouthaving to install or maintain the infrastructure normally used toimplement the directory service.

However, existing managed directory services have several limitations.For example, as described above, user management may be performed usinga member server added to the domain. Some administrators, though, maynot have access to a member server or may not wish to operate a memberserver (e.g., web developers, application developers, mobile applicationdevelopers, etc.), and thus may not be able to perform any usermanagement or otherwise manage the resources of a directory. As anotherexample, an administrator may have created multiple directories, but themanaged directory service may only allow the administrator to access andmanage one directory at a time. Applications or services (whetherrunning on a user's device or accessible via a network) that do not havedirect access to the list of created users in a domain or directory maynot be able to access the domain or directory. Thus, it may not bepossible for an administrator or user using an application or serviceassociated with one domain or directory to share resources or contentwith another domain (e.g., a domain that does not share the same tree orforest as the domain associated with the application or service) ordirectory.

Accordingly, the embodiments described herein present a user managementand authentication system that (1) allows administrators to perform usermanagement with devices that are not associated with a domain and toaccess a plurality of directories or domains via a set of applicationprogramming interfaces (APIs), and (2) provides authorization andauthentication mechanisms for allowing applications and services that donot have direct access to a list of created users to access a domain ordirectory. The user management and authentication system may be anadd-on system that works in conjunction with the managed directoryservice to provide the functionality described herein. For example, theuser management and authentication system may generate a set of loginpages (e.g., content or network pages, such as web pages) that can beaccessed by a device associated with an administrator. The administratorcan enter his or her credentials, a client identification thatidentifies an application or service that is requesting access to adomain, a redirect page (e.g., a page associated with an application orservice that the user management and authentication system shouldinstruct the user device to access once login is complete), and/or adirectory identifier (or domain identifier). The user management andauthentication system may transmit the credentials to the directoryassociated with the directory identifier, and the directory maydetermine whether the credentials can be authenticated (e.g., whetherthe administrator has access to the directory). If the credentials canbe authenticated, the user management and authentication system isnotified and generates an authentication code (e.g., an OAuth code).

The authentication code may be transmitted by the user management andauthentication system to the user device along with an instruction toaccess the redirect page. The authentication code may be a single-usecode that is valid for a set period of time (e.g., 10 minutes, 1 hour,etc.) and, before expiration of the authentication code, may be used bythe application or service associated with the redirect page to initiateaccess to the directory associated with the directory identifier. Forexample, the user management and authentication system may include agetToken API. The application or service may call the getToken API,passing the authentication code as a parameter.

The getToken API may generate an access token and/or a refresh token inresponse to receiving a valid authentication code and provide the tokensto the application or service. The access token and/or the refresh tokenmay be generated based on the credentials and/or the directoryidentifier. For example, the access token and/or the refresh token mayinclude the credentials and/or the directory identifier in a secureformat. The access token may allow the application or service to accessand/or manage the directory indicated by the directory identifier via aset of APIs and may be valid for an administrator-defined or presetperiod of time (e.g., 1 hour, 1 day, etc.). The refresh token may bevalid for an administrator-defined or preset period of time (e.g., 1week, 1 month, etc.) and can be used by the application or service toreceive a new access token once the previous access token expires. Insome embodiments, the refresh token may be valid for no amount of time(e.g., the access token may not be refreshed once it expires).

In an embodiment, the user management and authentication system providesseveral APIs. Such APIs may include user APIs, group APIs,organizational unit APIs, password APIs, access token APIs, and/orservice APIs. User APIs may include a createUser API (e.g., to create auser in a directory), a describeUsers API (e.g., to list all or anynumber of users within a directory and their attributes), an updateUserAPI (e.g., to update the attributes of a user in a directory), adeleteUser API (e.g., to delete a user from a directory), and/or alistGroupsForUser API (e.g., to list all or any number of users within adirectory and their groups). Group APIs may include a createGroup API(e.g., to create a new group within a directory), a describeGroups API(e.g., to list groups and attributes of the groups within a directory),an updateGroup API (e.g., to update an existing group in a directory), adeleteGroup API (e.g., to delete a group from a directory), alistMembersInGroup API (e.g., to list the members of groups in thedirectory), an addMemberToGroup API (e.g., to add members (users orgroups) to a group in a directory), and/or a removeMemberFromGroup API(e.g., to remove a member from a group in a directory). Organizationunit APIs may include a describeOrganizationalUnits API (e.g., to listall or any number of organizational units within a directory and theirattributes). Password APIs may include an authenticateUser API (e.g., toauthenticate a user in the directory and return an authentication code),an authenticateKerberosUser API (e.g., to authenticate a user in thedirectory and return an authentication code), an authenticateRadiusUserAPI (e.g., to authenticate a user against a radius server associatedwith a directory and return an authentication code), a resetPassword API(e.g., to reset a user's password), and/or a changePassword API (e.g.,to change a user's password). Access Token APIs may include acreateAnonymousToken API (e.g., to create an anonymous token to store),a getToken API (e.g., to generate an access and/or refresh token basedon an authentication code), a validateToken API (e.g., to verify that apreviously issued access token or anonymous token is still valid), arefreshToken API (e.g., to generate a new access token using apreviously issued refresh token), and/or a revokeToken API (e.g., toinvalidate a previously issued access, anonymous, or refresh token).Service APIs may include a getServiceAccountCreds API (e.g., to allow aregistered application or service to retrieve domain join credentials).

The application or service can use the access token to call any of theAPIs supported by the user management and authentication system. Forexample, the access token and/or other operation-specific parameters canbe provided to the user management and authentication system via an APIto manage a directory. As described above, the access token may begenerated based on the authentication code and/or the directoryidentifier. Thus, when unwrapped by the user management andauthentication system upon reception via the API, the access token mayidentify the authentication code, and thus the administrator that isperforming the action, and/or the directory that the action is to beperformed on. Accordingly, the application or service may not separatelyidentify the directory to be accessed and/or managed. Not separatelyidentifying the directory may provide an additional level of securitynot found in conventional systems. In conventional systems, whichgenerally involve accessing and managing a single directory, anadministrator may manage the directory simply by providing a directoryidentifier and/or other operation-specific parameters. However, in theembodiments disclosed herein, a user or administrator may not be able toaccess and manipulate a directory in an unauthorized manner simply byproviding a directory identifier and/or other operation-specificparameters. Rather, the access token is needed to access and/ormanipulate a specific directory, and the user or administrator mayobtain the access token only after his or her credentials can beverified with the specific directory (e.g., after the authenticationcode is received), as described herein.

In an embodiment, when generating the access token, the user managementand authentication system may map the access token to a directoryservice token (e.g., a Kerberos token, other directory-specificcredentials, etc.) that normally could be used by a member server toaccess the directory identified by the directory identifier. Thus, whenan application or service calls an API using the access token, the usermanagement and authentication system may access a database to determinethe token that maps to the access token, and pass the mapped token(and/or other operation-specific parameters provided by the applicationor service) to the managed directory service to perform the action oroperation requested via the calling of the API. In some embodiments, thevalidity of the refresh token may be tied to the validity of the mappedtoken (e.g., the lifetime of which can be preset or defined by anadministrator). Results, if any, may be returned by the manageddirectory service to the user management and authentication system, andthe user management and authentication system may forward the results tothe application or service.

The application or service can repeat this process to generate accesstokens for one or more directories operated by the administrator. Thus,the administrator, using an application or service, can access and/ormanage a plurality of directories.

In some embodiments, a directory service and a user management andauthentication system is assigned to a region (e.g., a physicallocation). A plurality of directory services and user management andauthentication systems may be present, separated by regions. Thedirectory service in one region may not interact with or access adirectory service or user management and authentication system inanother region. Likewise, the user management and authentication systemin one region may not interact with or access a directory service oruser management and authentication system in another region. In otherembodiments, a directory service and a user management andauthentication system is assigned to a region, but the directory serviceand/or the user management and authentication system may interact withdirectory services and/or user management and authentication systems inother regions.

In further embodiments, the user management and authentication systemsupports single-factor authentication and/or multi-factorauthentication. The user management and authentication system maysupport either type of authentication via user interfaces and/or APIs.The user management and authentication system may also support singlesign-on (e.g., an administrator may be able to login once and gainaccess to all appropriate directories without being prompted to log inagain each time a directory is accessed).

Example Network Environment

FIG. 1 shows an example network environment in which directorymanagement features and user, group, and device management andauthentication features of the present disclosure can be implementedaccording to some embodiments. As used herein the term “directory”generally refers to an organized collection of data about users,devices, applications, and other common resources of a computer network.Each resource on a computer network (or some subset thereof) may berepresented as an object in a directory, and information about aparticular resource (e.g., name, address, permissions, etc.) can bestored as attributes of that object. Information can be securely storedwithin or in association with the object such that only users withsufficient permissions are able to access, modify, or otherwise use theinformation.

As shown, the network environment includes various user devices 102, acomputing resource service provider system 104, organizations 106 andthird-party application servers 108 in communication via one or morenetworks 110. The computing resource service provider system 104 canprovide applications; directory management services; user, group, anddevice management and authentication services; and/or othernetwork-based services to various organizations or other customers.Organizations 106A-C (or other customers) can employ the computingresource service provider system 104 to provide application access tousers associated with the organizations, manage the organizations'directories, etc. Individual users can use user devices 102 to accessapplications hosted by the computing resource service provider system104 (or third-party application servers 108) using credentials fromtheir respective organizations 106A-106C. In addition, the computingresource service provider system 104 can provide the applications withaccess to the directories of the various organizations 106A-C at thediscretion of the respective organizations.

The user devices 102 can correspond to a wide variety of computingdevices, including desktop computing devices, laptop computing devices,terminal devices, mobile phones, tablet computing devices, mediaplayers, wearable computing devices (e.g., smart watches, smart eyewear,etc.), and various other electronic computing devices and applianceshaving one or more computer processors, computer-readable memory andnetwork-access capabilities. Some user devices 102 may be associatedwith a particular organization 106A-C. For example, an organization mayhave various user devices 102 that remain on-premises, or that are usedoff-premises primarily by employees, administrators, or other usersassociated with the organization. In some embodiments, some or all ofthe user devices 102 may be separate from any organization, such aspublic computers or home computers that are used by any number of usersto perform various tasks, which may include managing directories oraccessing applications using credentials associated with a particularorganization 106A-C or other customer of the computing resource serviceprovider system 104.

Individual user devices 102 may execute an application to communicatevia the network 110 with the computing resource service provider system104 in order to manage one or more directories and/or to access providedapplications or services. For example, the application may be astand-alone application that is installed on the user device 102. Asanother example, the application may be a browser (e.g., a web browser)that accesses an application or service (e.g., a web service) hosted bythe computing resource service provider system 104, the third-partyapplication server 108, and/or another computing system (not shown).

The computing resource service provider system 104 can be a computingsystem configured to host or otherwise provide access to applications144 (word processing applications, photo-editing applications,electronic mail applications, etc.), manage directories for separatecustomer organizations 106A-C, and/or provide other network-basedservices and resources (e.g., document-sharing services, virtual machineservices, etc.). For example, the computing resource service providersystem 104 can be a server or group of servers that may be accessed viaa communication network 110. The computing resource service providersystem 104 can include a number of components to provide variousfeatures described herein, such as a managed directory system or service140, a user management and authentication module 142, and one or moreapplications or application servers 144 that can be accessed byorganizations 106 and user devices 102. The computing resource serviceprovider system 104 may also store various off-premises directories 146,such as an off-premises directory for organization 160B, as describedbelow. In some embodiments, the computing resource service providersystem 104 may include additional or fewer components than illustratedin FIG. 1 to provide the features described above and in greater detailbelow.

As used herein, the term “off-premises directory” refers to a directorythat is remote from the organization with which it is associated, inorder to distinguish such a directory from a directory that is locatedon an organization's premises. Thus, although a directory may bephysically stored on the premises of a computing resource serviceprovider system 104, the directory may nevertheless be referred to as anoff-premises directory because it is off-premises with respect to theorganization with to which it belongs (e.g., the organization that ownsor operates the network described by the directory). Additionally,although a directory may be physically stored off the premises of thecomputing resource service provider system 104, the directory maynevertheless be referred to as an on-premises directory because it ison-premises with respect to the organization to which it belongs.

Illustratively, an administrator may use the application executed by theuser device 102 to manage one or more directories owned or operated bythe administrator's organization, such as one of organizations 106A-C.The application may interact with the managed directory service 140and/or the user management and authentication module 142. The manageddirectory service 140 may be a computing system that implements amanaged directory service. In an embodiment, the managed directoryservice 140 is configured to create, monitor, and manage one or moredirectories. For example, the managed directory service 140 may be incommunication with and manage the off-premises directory 146 and/or theon-premises directories 160. As described above, an administrator mayuse the managed directory service 140 to create, monitor, and/or managea directory if the user device 102 is a member server. However, if theuser device 102 is not a member server, the administrator may create,monitor, and/or manage the directory via APIs provided by the usermanagement and authentication module 142.

The user management and authentication module 142 may be a computingsystem that implements a user, group, and device management andauthentication system. In an embodiment, the user management andauthentication module 142 allows administrators to manage one or moredirectories with user devices 102 that are not member servers (e.g.,that are not associated with a domain of the respective directory) via aset of APIs, such as the APIs described above. The user management andauthentication module 142 may also provide authorization andauthentication mechanisms for allowing the application executed by theuser device 102 or applications or services accessed by the executedapplication to access content or resources in a directory even if theexecuted application or the accessed applications or services do nothave direct access to a list of created users of the directory. Forexample, the user management and authentication module 142 may be incommunication with the managed directory service 140 and may serve as aninterface between the user device 102 and the managed directory service140 such that the user device 102 can manage one or more directoriesmanaged by the managed directory service 140. The user device 102 cancall an API provided by the user management and authentication module142, and the user management and authentication module 142 can instructthe managed directory service 140 to perform an action indicated by thecalled API. The interaction between the user device 102, the manageddirectory service 140, and the user management and authentication module142 is described in greater detail below with respect to FIGS. 2A-2B.

In further embodiments, the user management and authentication module142 supports single-factor authentication and/or multi-factorauthentication. The user management and authentication module 142 maysupport either type of authentication via user interfaces and/or APIs.The user management and authentication module 142 may also supportsingle sign-on (e.g., an administrator may be able to login once andgain access to all appropriate directories without being prompted to login again each time a directory is accessed).

In an embodiment, applications or services provided by the third-partyapplication servers 108 or the computing resource service providersystem 104 that have registered with the computing resource serviceprovider system 104 may access the features described herein.Applications or services that have not registered with the computingresource service provider system 104 and/or that have not been approvedby administrators of the computing resource service provider system 104may be barred from accessing the features described herein.

The computing resource service provider system 104 may be a singlecomputing device, or it may include multiple distinct computing devices,such as computer servers, logically or physically grouped together tocollectively operate as a server system. The components of the computingresource service provider system 104 can each be implemented inapplication-specific hardware (e.g., a server computing device with oneor more ASICs) such that no software is necessary, or as a combinationof hardware and software. In addition, the modules and components of thecomputing resource service provider system 104 can be combined on oneserver computing device or separated individually or into groups onseveral server computing devices.

In addition, multiple (e.g., two or more) computing resource serviceprovider systems 104 may be used. For example, computing resourceservice provider systems 104 may be located in separate regions and mayor may not interact with each other. The separate computing resourceservice provider systems 104 may be located so that they are close (ineither a geographical or networking sense) to groups of current orpotential user devices 102 or organizations 160A-C.

In some embodiments, the features and services provided by the computingresource service provider system 104 may be implemented as web servicesconsumable via the communication network 110. In further embodiments,the computing resource service provider system 104 is provided by onemore virtual machines implemented in a hosted computing environment. Thehosted computing environment may include one or more rapidly provisionedand released computing resources, which computing resources may includecomputing, networking and/or storage devices. A hosted computingenvironment may also be referred to as a cloud computing environment.

The organizations 106A-C can correspond to various customers of thecomputing resource service provider system 104. Although the term“organization” is used herein, the features involving such organizationsmay additionally or alternatively involve any customer having adirectory (whether on-premises or off-premises) and wishing to use thecomputing resource service provider system 104 to manage the directoryand control access to the directory by applications hosted by thecomputing resource service provider 104 or third-party applicationservers 108.

Organizations that maintain on-premises directories 160 may have one ormore servers on which the directories 160 are stored. For example,organization 106A may have a data center that includes various servers,and an on-premises directory 160 may be stored on one or more of theservers. Organizations that maintain off-premises directories may employthe services of the computing resource service provider system 104,which may store the off-premises directory in an off-premises directorydata store 146. For example, organization 106B may not maintain anon-premises directory at all, but may rely instead on the computingresource service provider system 104 to maintain the organization'sdirectory 146. Some organizations may choose to maintain multipledirectories on-premises and/or off-premises. For example, organization106C may store multiple on-premises directories 160, each in a mannersimilar to organization 106A (described above), and the organization106C may also choose to employ the computing resource service providersystem 104 to maintain an off-premises directory 146. The directory 146maintained by the computing resource service provider system 104 in thisexample may be a mirror or subset of the on-premises directory (e.g. forbackup or disaster-recovery purposes), or it may be a separate directoryaltogether (e.g., a directory of computing resources in a differentregion from the on-premises directory 160).

The communication network 110 may be a publicly accessible network oflinked networks, possibly operated by various distinct parties, such asthe Internet. In some embodiments, the communication network 110 may beor include the Internet, a private network, personal area network, localarea network, wide area network, cable network, satellite network,cellular telephone network, etc. or combination thereof.

Example Interactions to and from the User Management and AuthenticationModule

FIG. 2A shows interactions to and from the user management andauthentication module 142 during the process of providing a serviceaccessed by a user device with tokens. As illustrated in FIG. 2A, thedirectory service module 140 may interact with a plurality of agents215A-B, and the agents 215A-B may interact with the user management andauthentication module 142.

In an embodiment, each agent 215A-B is associated with one or moreseparate directories and directly interfaces with its associateddirectories for management purposes. The agents 215A-B may be associatedwith and communicate with on-premises and/or off-premises directories.For example, the agent 215A may be associated with the off-premisesdirectory 146 and the agent 215B may be associated with the on-premisesdirectory 160. The managed directory service 140 may be configured tocreate, monitor, and/or manage the agents 215A-B. While two agents215A-B are illustrated, this is not meant to be limiting. The computingresource service provider system 104 may include any number of agents(e.g., a number of agents sufficient to handle all directories managedby the managed directory service 140).

The agents 215A-B may receive translated versions of API calls made tothe user management and authentication module 142. The translatedversions of the API calls made to the user management and authenticationmodule 142 may be directory-specific API calls (e.g., LDAP, Kerberos,DNS, etc.) that can be executed by the managed directory service 140. Asan example, translation of the API calls may include mapping an accesstoken to a directory service token (e.g., a Kerberos token, a usernameand password pair, an NT LAN manager (NTLM) hash, etc.).

In an embodiment, the user management and authentication module 142includes a console 220, a control plane 225, and load balancers 230 and235. The console 220 may be configured to generate user interfaces thatare transmitted to the user devices 102. The user interfaces may belogin pages that may be transmitted to a user device 102 when a userdevice 102 calls an API provided by the user management andauthentication module 142 to login, reset a password, change a password,and/or perform other operations described herein. The console 220 mayalso generate a link (e.g., a uniform resource locator (URL)) that canbe transmitted to the user device 102, such as, for example, when a newuser is created. The link may be valid for a finite period of time(e.g., 7 days, 2 weeks, etc.) and, when selected, may redirect theapplication executed by the user device 102 to a content page thatallows the administrator to enter additional information, such as userprofile information. The console 220 may also transmit an electronicmessage (e.g., email, text message, etc.) that includes the link to anaccount associated with an administrator when a user device 102 calls anAPI provided by the user management and authentication module 142 toreset a password. The electronic message may include a one-time usertoken that can be used by the user device 102 to complete the passwordreset process.

The control plane 225 may be configured to expose APIs to the userdevices 102. For example, the control plane 225 may expose APIs like theAPIs described herein. The control plane 225 may also be configured tointeract with the agents 215A-B. For example, the control plane 225 maytranslate the API calls received from the user devices 102 intodirectory-specific API calls that can be executed by the manageddirectory service 140 and provide the directory-specific API calls tothe appropriate agent 215A-B (e.g., the agent associated with thedirectory on which an action is to be performed according to the APIcall). The control plane 225 is described in greater detail below withrespect to FIG. 2B.

The console 220 and the control plane 225 may each be behind a loadbalancer 230 or 235. The console 220 and the control plane 225 may eachinclude multiple computing resources and the load balancers 230 and 235may distribute workloads across the multiple computing resources tooptimize resource use, to maximize throughput, and/or to minimize therisk that any single resources becomes overloaded. For example, the loadbalancers 230 and 235 may receive API calls from the user device 102 anddistribute the API calls to the appropriate computing resources of theconsole 220 or the control plane 225.

At (1), an administrator, via the user device 102, may first communicatewith the load balancer 235 to authenticate his or her credentials. Theload balancer 235 may forward the authentication request and credentialsto the console 220, which may forward the authentication request andcredentials to the load balancer 230. The load balancer 230 may forwardthe authentication request and credentials to the control plane 225. Thecontrol plane 225 may determine a directory associated with thecredentials and transmit the authentication request and credentials tothe appropriate agent 215A or 215B. Once the appropriate agent 215A or215B receives the authentication request and credentials, the agent 215Aor 215B may perform the authentication by contacting its associateddirectory (e.g., off-premises directory 146 or on-premises directory160).

At (2), in response to a determination that the administrator'scredentials can be authenticated, the control plane 225 generates anauthentication code. The control plane 225 transmits the authenticationcode to the load balancer 230 for forwarding to the user device 102.

At (3), the user device 102 accesses a service provided by thethird-party application servers 108. In alternative embodiments, notshown, the user device 102 accesses an application in the applications144 provided by the computer resource service provider system 104.

At (4), the accessed service transmits the authentication code to theload balancer 230 for the purpose of receiving an access token and/or arefresh token. The load balancer 230 may forward the authentication codeto the control plane 225.

At (5), the control plane 225 generates the access token and/or therefresh token based on the received authentication code. The controlplane 225 may generate the access token if the authentication code isreceived before expiration. The control plane 225 may transmit theaccess token and/or the refresh token to the load balancer 230 forforwarding to the accessed service.

FIG. 2B shows interactions to and from the user management andauthentication module 142 during the process of providing tokens andhandling API calls. As illustrated in FIG. 2B, the control plane 225 mayinclude a user, group, and password APIs module 240, an authenticationAPI module 245, an authentication token to credential mapper module 250,a directory lookup module 255, a directory database 260, a servicehealth monitoring module 265, and an authentication lifetime managementreaper module 270. In alternate embodiments, not shown, the directorylookup module 255 is a component of an agent 215A or 215B.

The authentication API module 245 may generate an authentication code, arefresh token, and/or an access token. For example, the authenticationAPI module 245 may receive administrator credentials, a clientidentification that identifies an application or service hosted by theapplications server 140 that is requesting access to a domain, aredirect page (e.g., a page associated with an application or servicethat the user management and authentication module 150 should instructthe user device 102 to access once authentication is complete), and/or adirectory identifier (or domain identifier). The authentication APImodule 245 may transmit the credentials to the agent 215A or 215B thatcorresponds with a directory associated with the directory identifier.The agent 215A or 215B may pass the credentials to the directory servicemodule 140 to determine whether the credentials can be authenticated(e.g., whether the administrator has access to the directory). If thecredentials can be authenticated, the authentication API module 245 isnotified and generates an authentication code (e.g., an OAuth code).

At (1), as described above, the authentication code may be a single-usecode that is valid for a finite period of time (e.g., 10 minutes, 1hour, etc.). The authentication API module 245 may transmit theauthentication code to the user device 102. The authentication APImodule 245 may also transmit to the user device 102 an instruction toaccess the redirect page.

At (2), the user device 102 accesses a service provided by thethird-party application servers 108. In alternative embodiments, notshown, the user device 102 accesses an application in the applications144 provided by the computer resource service provider system 104.

At (3), the authentication API module 245 receives the authenticationcode from the accessed service (e.g., accessed via a browser). Forexample, the authentication API module 245 may receive theauthentication code if the getToken API is called (e.g., theauthentication code may be included as parameter).

If an unexpired authentication code is received, the authentication APImodule 245 may generate an access token and/or a refresh token. Theaccess token and/or the refresh token may be generated based on thecredentials and/or the directory identifier. For example, whenunwrapped, the access token and/or the refresh token may indicate theauthentication code (and thus the credentials and administratorassociated with the credentials) and the directory identifier associatedwith the token. The access token may allow the accessed service tomanage the directory indicated by the directory identifier via a set ofAPIs provided by the user, group, and password APIs module 240. Theaccess token may be valid for an administrator-defined or finite periodof time (e.g., 1 hour, 1 day, etc.). The refresh token may be valid foran administrator-defined or finite period of time (e.g., 1 week, 1month, etc.) and can be used by the user device 102 and/or the accessedapplication or service to receive a new access token once the previousaccess token expires. In some embodiments, the refresh token may not bevalid for any period of time (e.g., the access token may not berefreshed once it expires.

At (4), in some embodiments, the authentication API module 245 transmitsthe access token, the refresh token, the credentials, and/or thedirectory identifier to the authentication token to credential mappermodule 250. The authentication token to credential mapper module 250 mayuse underlying directory logic to map the credentials and/or thedirectory identifier to the access token and/or the refresh token andstore this mapping in the directory database 260.

At (5), the authentication API module 245 may also transmit the accesstoken and/or the refresh token to the accessed service. The user, group,and password APIs module 240 may provide one or more of the APIsdescribed above, and the accessed service may use the access tokenand/or other operation-specific parameters to call one or more of theprovided APIs. In some embodiments, not shown, the authentication APImodule 245 transmits the access and/or refresh tokens to the accessedservice before performing the operations discussed with respect to (4).

At (6), in an embodiment, upon receiving an API call that includes anaccess token from a calling service, the user, group, and password APIsmodule 240 identifies a directory associated with the access token byquerying the directory lookup module 255. For example, the directorylookup module 255 may pass the access token to the directory database260 and identify a directory associated with the access token,transmitting the identified directory back to the user, group, andpassword APIs module 240.

At (7), the user, group, and password APIs module 240 may then identifyan agent 215A or 215B associated with the identified directory,translate the API call into a directory-specific API call, and pass thedirectory-specific API call and its operation-specific parameters to theappropriate agent 215A or 215B. The user, group, and password APIsmodule 240 may determine how to translate the API call into adirectory-specific API call based on information provided by thedirectory lookup module 255. In alternate embodiments, not shown, theuser, group, and password APIs module 240 directly identifies adirectory associated with the access token without querying thedirectory lookup module 255 (e.g., via an internal lookup table ordatabase).

As described above, the agents 215A-B may receive directory-specific APIcalls translated from API calls received by the user, group, andpassword APIs module 240. As an example, the user, group, and passwordAPIs module 240 may map the access token received by the user, group,and password APIs module 240 to a directory service token (e.g., aKerberos token), and the directory service token may be provided to theagents 215A-B to access the appropriate directory.

At (8), results, if any, may be received by the agents 215A-B from themanaged directory service 140 and forwarded to the user, group, andpassword APIs module 240. The user, group, and password APIs module 240may then transmit the results to the calling service.

The service health monitoring module 265 may be a computing system thatmonitors the health of a directory service. For example, the servicehealth monitoring module 265 may monitor the health of the directoryservice module 140.

The authentication lifetime management reaper module 270 may performmaintenance on the directory database 260. For example, theauthentication lifetime management reaper module 270 may reap out orremove access tokens and/or refresh tokens that have expired (and theirassociated credentials and directory identification).

Example Process for Authenticating an Administrator and Providing anAccess Token

FIG. 3 illustrates an authentication process 300 that may be used by acomputing resource service provider system to authenticate anadministrator and provide the administrator with an access token thatcan be used to call APIs provided by the computing resource serviceprovider system to manage one or more directories. As an example, thecomputing resource service provider system 104 (e.g., the usermanagement and authentication module 142) of FIG. 1 can be configured toexecute the authentication process 300. The authentication process 300begins at block 302.

At block 304, a credential and a directory identifier associated with afirst directory in a plurality of directories are received from a userdevice. In an embodiment, a client identification that identifies aservice that is not associated with the first directory is alsoreceived.

At block 306, whether the credential can be authenticated is determined.In an embodiment, the credential is authenticated by passing thecredential to the first directory.

At block 308, in response to a determination that the credential can beauthenticated, an authentication code is generated. The authenticationcode may be an OAuth code and may be valid for a finite period of time.

At block 310, the authentication code is transmitted to the user device.For example, the authentication code is received by an application(e.g., browser) executed by the user device. In other embodiments, theauthentication code is transmitted to an application or service hostedby an applications server and accessed by the user device.

At block 312, the authentication code is received from a calling serviceaccessed by the user device. The calling service be an application orservice that the user device has accessed (e.g., via the browser). Theauthentication code may be received before the authentication codeexpires.

At block 314, an access token is generated based on the authenticationcode and/or the directory identifier. For example, when unwrapped, theaccess token may identify the authentication code (e.g., which mayinclude the credential that identifies the administrator) and thedirectory identifier. The access token may be valid for a finite periodof time. In some embodiments, a refresh token is also generated. Therefresh token may be valid for a finite period of time and may be usedto generate a new access token when the previous access token expires.

At block 316, the access token is transmitted to the calling serviceaccessed by the user device. In an embodiment, the user device uses theaccess token to allow an administrator to manage the directorycorresponding to the directory identifier (e.g., the first directory)via the calling service. After the access token is transmitted to thecalling service, the authentication process 300 may be complete, asshown in block 318.

Example Process for Using an Access Token

FIG. 4 illustrates an access token usage process 400 that may be used bya computing resource service provider system to allow an administratorto manage one or more directories. As an example, the computing resourceservice provider system 104 (e.g., the user management andauthentication module 142) of FIG. 1 can be configured to execute theaccess token usage process 400. The access token usage process 400begins at block 402.

At block 404, a call for an operation from an application service incommunication with a user device is received, where the call includes anaccess token and an operation-specific parameter. For example, the userdevice, via an application or service, may call an API, such as thecreateUser API, passing the access token and a username asoperation-specific parameters. The operation-specific parameters passedvia the API may include all operation-specific parameters required bythe API schema associated with the called operation.

At block 406, the access token usage process 400 determines whether theaccess token is valid. For example, the access token usage process 400determines whether the access token is valid in time (e.g., determineswhether the access token has expired) and, if the access token is validin time, whether the access token is valid for the application or theservice that the user device is attempting to access (e.g., the manageddirectory service). If the access token is valid, the access token usageprocess 400 proceeds to block 408. Otherwise, the access toke usageprocess 400 finishes at block 416.

At block 408, a directory associated with the access token may bedetermined. In an embodiment, the access token is mapped to a directorywhen the access token is generated and the mapping is stored in adatabase, such as the directory database 260. A directory lookup module,such as the directory lookup module 255 may query the directory database260 to determine a directory associated with the received access token.

At block 410, an indication of the operation and the operation-specificparameter are transmitted to an agent associated with the determineddirectory. In further embodiments, the user management andauthentication module 142 maps the access token to a directory servicetoken (e.g., a Kerberos token, a username and password pair, an NTLMhash, etc.) and the directory service token is also provided to theagent. In an embodiment, an agent is associated with a directory. Thedirectory service token, an indication of the operation, and/or theoperation-specific parameter may then be transmitted to the appropriateagent. The agent may use the received data to instruct the manageddirectory service, such as the managed directory service 140, to performthe operation specified by the called API.

At block 412, results from the agent are received. The results may bedata received from the agent once the operation specified by the APIcall is complete.

At block 414, the received results are transmitted to the applicationservice. After the received results are transmitted to the applicationservice, the access token usage process 400 may be complete, as shown inblock 416.

Terminology

All of the methods and tasks described herein may be performed and fullyautomated by a computer system. The computer system may, in some cases,include multiple distinct computers or computing devices (e.g., physicalservers, workstations, storage arrays, cloud computing resources, etc.)that communicate and interoperate over a network to perform thedescribed functions. Each such computing device typically includes aprocessor (or multiple processors) that executes program instructions ormodules stored in a memory or other non-transitory computer-readablestorage medium or device (e.g., solid state storage devices, diskdrives, etc.). The various functions disclosed herein may be embodied insuch program instructions, and/or may be implemented inapplication-specific circuitry (e.g., ASICs or FPGAs) of the computersystem. Where the computer system includes multiple computing devices,these devices may, but need not, be co-located. The results of thedisclosed methods and tasks may be persistently stored by transformingphysical storage devices, such as solid state memory chips and/ormagnetic disks, into a different state. In some embodiments, thecomputer system may be a cloud-based computing system whose processingresources are shared by multiple distinct business entities or otherusers.

Depending on the embodiment, certain acts, events, or functions of anyof the processes or algorithms described herein can be performed in adifferent sequence, can be added, merged, or left out altogether (e.g.,not all described operations or events are necessary for the practice ofthe algorithm). Moreover, in certain embodiments, operations or eventscan be performed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors or processor cores or onother parallel architectures, rather than sequentially.

The various illustrative logical blocks, modules, routines, andalgorithm steps described in connection with the embodiments disclosedherein can be implemented as electronic hardware (e.g., ASICs or FPGAdevices), computer software that runs on general purpose computerhardware, or combinations of both. To clearly illustrate thisinterchangeability of hardware and software, various illustrativecomponents, blocks, modules, and steps have been described abovegenerally in terms of their functionality. Whether such functionality isimplemented as specialized hardware versus software running ongeneral-purpose hardware depends upon the particular application anddesign constraints imposed on the overall system. The describedfunctionality can be implemented in varying ways for each particularapplication, but such implementation decisions should not be interpretedas causing a departure from the scope of the disclosure.

Moreover, the various illustrative logical blocks and modules describedin connection with the embodiments disclosed herein can be implementedor performed by a machine, such as a general purpose processor device, adigital signal processor (DSP), an application specific integratedcircuit (ASIC), a field programmable gate array (FPGA) or otherprogrammable logic device, discrete gate or transistor logic, discretehardware components, or any combination thereof designed to perform thefunctions described herein. A general purpose processor device can be amicroprocessor, but in the alternative, the processor device can be acontroller, microcontroller, or state machine, combinations of the same,or the like. A processor device can include electrical circuitryconfigured to process computer-executable instructions. In anotherembodiment, a processor device includes an FPGA or other programmabledevice that performs logic operations without processingcomputer-executable instructions. A processor device can also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration. Although described herein primarily with respect todigital technology, a processor device may also include primarily analogcomponents. For example, some or all of the rendering techniquesdescribed herein may be implemented in analog circuitry or mixed analogand digital circuitry. A computing environment can include any type ofcomputer system, including, but not limited to, a computer system basedon a microprocessor, a mainframe computer, a digital signal processor, aportable computing device, a device controller, or a computationalengine within an appliance, to name a few.

The elements of a method, process, routine, or algorithm described inconnection with the embodiments disclosed herein can be embodieddirectly in hardware, in a software module executed by a processordevice, or in a combination of the two. A software module can reside inRAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory,registers, hard disk, a removable disk, a CD-ROM, or any other form of anon-transitory computer-readable storage medium. An exemplary storagemedium can be coupled to the processor device such that the processordevice can read information from, and write information to, the storagemedium. In the alternative, the storage medium can be integral to theprocessor device. The processor device and the storage medium can residein an ASIC. The ASIC can reside in a user terminal. In the alternative,the processor device and the storage medium can reside as discretecomponents in a user terminal.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.,” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements and/orsteps. Thus, such conditional language is not generally intended toimply that features, elements and/or steps are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without other input or prompting,whether these features, elements and/or steps are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having,” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations, and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some, or all of the elements in the list.

Disjunctive language such as the phrase “at least one of X, Y, Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

While the above detailed description has shown, described, and pointedout novel features as applied to various embodiments, it can beunderstood that various omissions, substitutions, and changes in theform and details of the devices or algorithms illustrated can be madewithout departing from the spirit of the disclosure. As can berecognized, certain embodiments described herein can be embodied withina form that does not provide all of the features and benefits set forthherein, as some features can be used or practiced separately fromothers. The scope of certain embodiments disclosed herein is indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A computer-implemented method comprising:receiving, from an application service, a request for an operation,wherein the request includes an access token; determining that a firstdirectory in a plurality of directories is associated with the accesstoken; identifying that a first agent is associated with the firstdirectory; transmitting a translated version of the request to the firstagent, wherein receipt of the translated version of the request resultsin the first directory performing the operation; receiving results ofthe performed operation from the first agent; and transmitting theresults of the performed operation to the application service.
 2. Thecomputer-implemented method of claim 1, wherein receipt of thetranslated version of the request causes the first agent to cause theoperation to be performed.
 3. The computer-implemented method of claim1, wherein a user device that causes transmission of the request for theoperation is not associated with the first directory.
 4. Thecomputer-implemented method of claim 1, further comprising determiningthat the access token is valid in time and for a managed directoryservice that a user device is attempting to access.
 5. Thecomputer-implemented method of claim 1, wherein determining that a firstdirectory in the plurality of directories is associated with the accesstoken further comprises querying a directory database that comprises anassociation between the access token and the first directory in theplurality of directories.
 6. The computer-implemented method of claim 1,wherein the request further includes a parameter corresponding to theoperation.
 7. The computer-implemented method of claim 6, wherein theoperation comprises adding a user to the first directory based on theparameter.
 8. The computer-implemented method of claim 7, wherein thefirst agent instructs the first directory to add the user to the firstdirectory using the parameter.
 9. The computer-implemented method ofclaim 6, wherein the parameter comprises a password.
 10. A systemcomprising: a computing system that hosts a first directory in aplurality of directories; and a computing resource service providersystem, the computing resource service provider system in communicationwith the computing system, the computer resource service provider systemconfigured with specific executable instructions that, when executed,cause the computing resource service provider system to at least:receive, from an application service, a request for an operation,wherein the request includes an access token; determine that the firstdirectory is associated with the access token; identify that a firstagent is associated with the first directory; transmit a translatedversion of the request to the first agent, wherein receipt of thetranslated version of the request results in the first directoryperforming the operation; receive results of the performed operationfrom the first agent; and transmit the results of the performedoperation to the application service.
 11. The system of claim 10,wherein receipt of the translated version of the request causes thefirst agent to cause the operation to be performed.
 12. The system ofclaim 10, wherein a user device that causes transmission of the requestfor the operation is not associated with the first directory.
 13. Thesystem of claim 10, wherein the specific executable instructions, whenexecuted, further cause the computing resource service provider systemto at least determine that the access token is valid in time and for amanaged directory service that a user device is attempting to access.14. The system of claim 10, wherein the specific executableinstructions, when executed, further cause the computing resourceservice provider system to at least query a directory database thatcomprises an association between the access token and the firstdirectory in the plurality of directories.
 15. The system of claim 10,wherein the request further includes a parameter corresponding to theoperation.
 16. The system of claim 15, wherein the operation comprisesadding a user to the first directory based on the parameter.
 17. Anon-transitory computer storage system comprising a non-transitorystorage device, said computer storage system having stored thereonexecutable program instructions that direct a computer system to atleast: receive, from an application service, a request for an operation,wherein the request includes an access token; determine that a firstdirectory in a plurality of directories is associated with the accesstoken; identify that a first agent is associated with the firstdirectory; transmit a translated version of the request to the firstagent, wherein receipt of the translated version of the request resultsin the first directory performing the operation; receive results of theperformed operation from the first agent; and transmit the results ofthe performed operation to the application service.
 18. Thenon-transitory computer storage system of claim 17, wherein receipt ofthe translated version of the request causes the first agent to causethe operation to be performed.
 19. The non-transitory computer storagesystem of claim 17, wherein a user device that causes transmission ofthe request for the operation is not associated with the firstdirectory.
 20. The non-transitory computer storage system of claim 17,wherein the executable program instructions further direct the computersystem to at least determine that the access token is valid in time andfor a managed directory service that a user device is attempting toaccess.
 21. A computer-implemented method comprising: receiving, from anapplication service, a request for an operation, wherein the requestincludes an access token and a parameter corresponding to the operation,and wherein the operation comprises adding a user to a first directoryin a plurality of directories based on the parameter; determining thatthe first directory is associated with the access token; identifyingthat a first agent is associated with the first directory; transmittinga translated version of the request to the first agent, wherein receiptof the translated version of the request causes the first agent toinstruct the first directory to add the user to the first directoryusing the parameter; receiving results of the performed operation fromthe first agent; and transmitting the results of the performed operationto the application service.